home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / public / bit / src / jpeg / SETUP < prev    next >
Text File  |  1994-08-01  |  26KB  |  523 lines
  1. SETUP instructions for the Independent JPEG Group's JPEG software
  2. =================================================================
  3.  
  4. This file explains how to configure and compile the JPEG software.  We have
  5. tried to make this software extremely portable and flexible, so that it can be
  6. adapted to almost any environment.  The downside of this decision is that the
  7. installation process is not very automatic; you will need at least a little
  8. familiarity with C programming and program build procedures for your system.
  9.  
  10. This file contains general instructions, then sections of specific hints for
  11. certain systems.  You may save yourself considerable time if you scan the
  12. whole file before starting to do anything.
  13.  
  14. Before installing the software you must unpack the distributed source code.
  15. Since you are reading this file, you have probably already succeeded in this
  16. task.  However, there is one potential trap if you are on a non-Unix system:
  17. you may need to convert these files to the local standard text file format
  18. (for example, if you are on MS-DOS you probably have to convert LF end-of-line
  19. to CR/LF).  If so, apply the conversion to all the files EXCEPT those whose
  20. names begin with "test".  The test files contain binary data; if you change
  21. them in any way then the self-test will give bad results.
  22.  
  23.  
  24. STEP 1: PREPARE A MAKEFILE
  25. ==========================
  26.  
  27. First, select a makefile and copy it to "Makefile" (or whatever your version
  28. of make uses as the default makefile name; for example, "makefile.mak" for
  29. old versions of Borland C).  We include several standard makefiles in the
  30. distribution:
  31.  
  32.     makefile.ansi:    for Unix systems with ANSI-compatible C compilers.
  33.     makefile.unix:    for Unix systems with non-ANSI C compilers.
  34.     makefile.mc5:    for Microsoft C 5.x under MS-DOS.
  35.     makefile.mc6:    for Microsoft C 6.x and up under MS-DOS.
  36.     makefile.bcc:    for Borland C (Turbo C) under MS-DOS.
  37.     makefile.manx:    for Manx Aztec C on Amigas.
  38.     makefile.sas:    for SAS C on Amigas.
  39.     makcjpeg.st:    project file for Atari ST/STE/TT Pure C or Turbo C.
  40.     makdjpeg.st:    project file for Atari ST/STE/TT Pure C or Turbo C.
  41.     makljpeg.st:    project file for Atari ST/STE/TT Pure C or Turbo C.
  42.     makefile.mms:    for VAX/VMS systems with MMS.
  43.     makefile.vms:    for VAX/VMS systems without MMS.
  44.  
  45. If you don't see a makefile for your system, we recommend starting from either
  46. makefile.ansi or makefile.unix, depending on whether your compiler accepts
  47. ANSI C or not.  Actually you should start with makefile.ansi whenever your
  48. compiler supports ANSI-style function definitions; you don't need full ANSI
  49. compatibility.  The difference between the two makefiles is that makefile.unix
  50. preprocesses the source code to convert function definitions to old-style C.
  51. (Our thanks to Peter Deutsch of Aladdin Enterprises for the ansi2knr program.)
  52.  
  53. If you don't know whether your compiler supports ANSI-style function
  54. definitions, then take a look at ckconfig.c.  It is a test program that will
  55. help you figure out this fact, as well as some other facts you'll need in
  56. later steps.  You must compile and execute ckconfig.c by hand; the makefiles
  57. don't provide any support for this.  ckconfig.c may not compile the first try
  58. (in fact, the whole idea is for it to fail if anything is going to).  If you
  59. get compile errors, fix them by editing ckconfig.c according to the directions
  60. given in ckconfig.c.  Once you get it to run, select a makefile according to
  61. the advice it prints out, and make any other changes it recommends.
  62.  
  63. Look over the selected Makefile and adjust options as needed.  In particular
  64. you may want to change the CC and CFLAGS definitions.  For instance, if you
  65. are using GCC, set CC=gcc.  If you had to use any compiler switches to get
  66. ckconfig.c to work, make sure the same switches are in CFLAGS.
  67.  
  68. If you are on a system that doesn't use makefiles, you'll need to set up
  69. project files (or whatever you do use) to compile all the source files and
  70. link them into executable files cjpeg and djpeg.  See the file lists in any of
  71. the makefiles to find out which files go into each program.  As a last resort,
  72. you can make a batch script that just compiles everything and links it all
  73. together; makefile.vms is an example of this (it's for VMS systems that have
  74. no make-like utility).
  75.  
  76.  
  77. STEP 2: EDIT JCONFIG.H
  78. ======================
  79.  
  80. Look over jconfig.h and adjust #defines to reflect the properties of your
  81. system and C compiler.  If you prefer, you can usually leave jconfig.h
  82. unmodified and add -Dsymbol switches to the Makefile's CFLAGS definition.
  83. (This is already done if you used a compiler-specific makefile in step 1.)
  84. However, putting the switches in the Makefile is a bad idea if you are going
  85. to incorporate the JPEG software into other programs --- you'd need to include
  86. the same -D switches in the other programs' Makefiles.  Better to change
  87. jconfig.h.
  88.  
  89. If you have an ANSI-compliant C compiler, no changes should be necessary
  90. except perhaps for RIGHT_SHIFT_IS_UNSIGNED and TWO_FILE_COMMANDLINE.  For
  91. older compilers other changes may be needed, depending on what ANSI features
  92. are supported.
  93.  
  94. If you don't know enough about C programming to understand the questions in
  95. jconfig.h, then use ckconfig.c to figure out what to change.  (See description
  96. of ckconfig.c in step 1.)
  97.  
  98. A note about TWO_FILE_COMMANDLINE: defining this selects the command line
  99. syntax in which the input and output files are both named on the command line.
  100. If it's not defined, the output image goes to standard output, and the input
  101. can optionally come from standard input.  You MUST use two-file style on any
  102. system that doesn't cope well with binary data fed through stdin/stdout; this
  103. is true for most MS-DOS compilers, for example.  If you're not on a Unix
  104. system, it's probably safest to assume you need two-file style.
  105.  
  106.  
  107. STEP 3: SELECT SYSTEM-DEPENDENT FILES
  108. =====================================
  109.  
  110. A few places in the JPEG software are so system-dependent that we have to
  111. provide several different implementations and let you select the one you need.
  112.  
  113. The only system-dependent file in the current version is jmemsys.c.  This file
  114. controls use of temporary files for big images that won't fit in main memory.
  115. You'll notice there is no file named jmemsys.c in the distribution; you must
  116. select one of the provided versions and copy, rename, or link it to jmemsys.c.
  117. Here are the provided versions:
  118.  
  119.     jmemansi.c    This is a reasonably portable version that should
  120.             work on most ANSI and near-ANSI C compilers.  It uses
  121.             the ANSI-standard library routine tmpfile(), which not
  122.             all non-ANSI systems have.  On some systems tmpfile()
  123.             may put the temporary file in a non-optimal location;
  124.             if you don't like what it does, use jmemname.c.
  125.  
  126.     jmemname.c    This version constructs the temp file name by itself.
  127.             For anything except a Unix machine, you'll need to
  128.             configure the select_file_name() routine appropriately;
  129.             see the comments near the head of jmemname.c.
  130.             If you use this version, define NEED_SIGNAL_CATCHER
  131.             in jconfig.h or in the Makefile to make sure the temp
  132.             files are removed if the program is aborted.
  133.  
  134.     jmemnobs.c    (That stands for No Backing Store :-).  This will
  135.             compile on almost any system, but it assumes you
  136.             have enough main memory or virtual memory to hold
  137.             the biggest images you need to work with.
  138.  
  139.     jmemdos.c    This should be used in most MS-DOS installations; see
  140.             the system-specific notes about MS-DOS for more info.
  141.             IMPORTANT: if you use this, also copy jmemdos.h to
  142.             jmemsys.h, replacing the standard version.  ALSO,
  143.             include the assembly file jmemdosa.asm in the programs.
  144.             (This last is already done if you used one of the
  145.             supplied MS-DOS-specific makefiles.)
  146.  
  147. If you have plenty of (real or virtual) main memory, just use jmemnobs.c.
  148. "Plenty" means at least ten bytes for every pixel in the largest images
  149. you plan to process, so a lot of systems don't meet this criterion.
  150. If yours doesn't, try jmemansi.c first.  If that doesn't compile, you'll have
  151. to use jmemname.c; be sure to adjust select_file_name() for local conditions.
  152. You may also need to change unlink() to remove() in close_backing_store().
  153.  
  154. Except with jmemnobs.c, you need to adjust the #define DEFAULT_MAX_MEM to a
  155. reasonable value for your system (either by editing jmemsys.c, or by adding
  156. a -D switch to the Makefile).  This value limits the amount of data space the
  157. program will attempt to allocate.  Code and static data space isn't counted,
  158. so the actual memory needs for cjpeg or djpeg are typically 100 to 150Kb more
  159. than the max-memory setting.  Larger max-memory settings reduce the amount of
  160. I/O needed to process a large image, but too large a value can result in
  161. "insufficient memory" failures.  On most Unix machines (and other systems with
  162. virtual memory), just set DEFAULT_MAX_MEM to several million and forget it.
  163. At the other end of the spectrum, for MS-DOS machines you probably can't go
  164. much above 300K to 400K.  (On MS-DOS the value refers to conventional memory;
  165. extended/expanded memory is handled separately by jmemdos.c.)
  166.  
  167.  
  168. STEP 4: MAKE
  169. ============
  170.  
  171. Now you should be able to "make" the software.
  172.  
  173. If you have trouble with missing system include files or inclusion of the
  174. wrong ones, look at jinclude.h (or use ckconfig.c, if you are not a C expert).
  175.  
  176. If your compiler complains about big_sarray_control and big_barray_control
  177. being undefined structures, you should be able to shut it up by adding
  178. -DINCOMPLETE_TYPES_BROKEN to CFLAGS (or add #define INCOMPLETE_TYPES_BROKEN
  179. to jconfig.h).  If you don't have a getenv() library routine, define NO_GETENV.
  180.  
  181. There are a fair number of routines that do not use all of their parameters;
  182. some compilers will issue warnings about this, which you can ignore.  Any
  183. other warning deserves investigation.
  184.  
  185.  
  186. STEP 5: TEST
  187. ============
  188.  
  189. As a quick test of functionality we've included a small sample image in
  190. several forms:
  191.     testorig.jpg    A reduced section of the well-known Lenna picture.
  192.     testimg.ppm    The output of djpeg testorig.jpg
  193.     testimg.gif    The output of djpeg -gif testorig.jpg
  194.     testimg.jpg    The output of cjpeg testimg.ppm
  195. (The two .jpg files aren't identical since JPEG is lossy.)  If you can
  196. generate duplicates of the testimg.* files then you probably have working
  197. programs.
  198.  
  199. With most of the makefiles, "make test" will perform the necessary
  200. comparisons.  If you're using a makefile that doesn't provide this option, run
  201. djpeg and cjpeg to generate testout.ppm, testout.gif, and testout.jpg, then
  202. compare these to testimg.* with whatever binary file comparison tool you have.
  203. The files should be bit-for-bit identical.
  204.  
  205. If the cjpeg test run fails with "Missing Huffman code table entry", it's a
  206. good bet that you needed to define RIGHT_SHIFT_IS_UNSIGNED.  Go back to step 2
  207. and run ckconfig.c.  (This is a good plan for any other test failure, too.)
  208.  
  209. If your choice of jmemsys.c was anything other than jmemnobs.c, you should
  210. test that temporary-file usage works.  Try "djpeg -gif -max 0 testorig.jpg"
  211. and make sure its output matches testimg.gif.  If you have any really large
  212. images handy, try compressing them with -optimize and/or decompressing with
  213. -gif to make sure your DEFAULT_MAX_MEM setting is not too large.
  214.  
  215. NOTE: this is far from an exhaustive test of the JPEG software; some modules,
  216. such as 1-pass color quantization, are not exercised at all.  It's just a quick
  217. test to give you some confidence that you haven't missed something major.
  218.  
  219.  
  220. STEP 6: INSTALLATION
  221. ====================
  222.  
  223. Once you're done with the above steps, you can install the software by copying
  224. the executable files (cjpeg and djpeg) to wherever you normally install
  225. programs.  On Unix systems, you'll also want to put cjpeg.1 and djpeg.1 in the
  226. corresponding manual directory.  (The makefiles don't support this step since
  227. there's such a wide variety of installation procedures on different systems.)
  228.  
  229. To learn to use the programs, read the file USAGE (or manual pages cjpeg(1)
  230. and djpeg(1) on Unix).
  231.  
  232.  
  233. OPTIMIZATION
  234. ============
  235.  
  236. Unless you own a Cray, you'll probably be interested in making the JPEG
  237. software go as fast as possible.  This section covers some machine-dependent
  238. optimizations you may want to try.  We suggest that before trying any of this,
  239. you first get the basic installation to pass the self-test (step 5 above).
  240. Repeat the self-test after any optimization to make sure that you haven't
  241. broken anything.
  242.  
  243. The JPEG DCT routines perform a lot of multiplications.  These multiplications
  244. must yield 32-bit results, but none of their input values are more than 16
  245. bits wide.  On many machines, notably the 680x0 and 80x86 CPUs, a 16x16=>32
  246. bit multiply instruction is faster than a full 32x32=>32 bit multiply.
  247. Unfortunately there is no portable way to specify such a multiplication in C,
  248. but some compilers can generate one when you use the right combination of
  249. casts.  See the MULTIPLY macro definitions in jfwddct.c and jrevdct.c.
  250. If your compiler makes "int" be 32 bits and "short" be 16 bits, defining
  251. SHORTxSHORT_32 is fairly likely to work.  When experimenting with alternate
  252. definitions, be sure to test not only whether the code still works (use the
  253. self-test step), but also whether it is actually faster --- on some compilers,
  254. alternate definitions may compute the right answer, yet be slower than the
  255. default.  Timing cjpeg on a large PPM input file is the best way to check
  256. this, as the DCT will be the largest fraction of the runtime in that mode.
  257. (Note: some of the distributed compiler-specific makefiles already contain
  258. -D switches to select an appropriate MULTIPLY definition.)
  259.  
  260. If access to "short" arrays is slow on your machine, it may be a win to define
  261. type DCTELEM as int rather than as JCOEF (which is normally defined as short).
  262. This will cause the DCT routines to operate on int arrays instead of short
  263. arrays.  If shorts are slow and you have lots of memory to burn, you might
  264. even make JCOEF itself be int.
  265.  
  266. If your compiler can compile function calls in-line, make sure the INLINE
  267. macro in jconfig.h is defined as the keyword that marks a function
  268. inline-able.  Some compilers have a switch that tells the compiler to inline
  269. any function it thinks is profitable (e.g., -finline-functions for gcc).
  270. Enabling such a switch is likely to make the compiled code bigger but faster.
  271.  
  272. In general, it's worth trying the maximum optimization level of your compiler,
  273. and experimenting with any optional optimizations such as loop unrolling.
  274. (Unfortunately, far too many compilers have optimizer bugs ... be prepared to
  275. back off if the code fails self-test.)  If you do any experimentation along
  276. these lines, please report the optimal settings to jpeg-info@uunet.uu.net so
  277. we can mention them in future releases.  Be sure to specify your machine and
  278. compiler version.
  279.  
  280.  
  281. OPTIONAL STUFF
  282. ==============
  283.  
  284. Progress monitor:
  285.  
  286. If you like, you can #define PROGRESS_REPORT (in jconfig.h or in the Makefile)
  287. to enable display of percent-done progress reports.  The routines provided in
  288. jcmain.c/jdmain.c merely print percentages to stderr, but you can customize
  289. them to do something fancier.
  290.  
  291. Utah RLE file format support:
  292.  
  293. We distribute the software with support for RLE image files (Utah Raster
  294. Toolkit format) disabled, because the RLE support won't compile without the
  295. Utah library.  If you have URT version 3.0, you can enable RLE support as
  296. follows:
  297.     1.  #define RLE_SUPPORTED in jconfig.h or in the Makefile.
  298.     2.  Add a -I option to CFLAGS in the Makefile for the directory
  299.         containing the URT .h files (typically the "include"
  300.         subdirectory of the URT distribution).
  301.     3.  Add -L... -lrle to LDLIBS in the Makefile, where ... specifies
  302.         the directory containing the URT "librle.a" file (typically the
  303.         "lib" subdirectory of the URT distribution).
  304.  
  305. JPEG library:
  306.  
  307. If you want to incorporate the JPEG code as subroutines in a larger program,
  308. we recommend that you make libjpeg.a, then link that into your surrounding
  309. program.  See file README for more info.
  310.  
  311. CAUTION: When you use the JPEG code as subroutines, we recommend that you make
  312. any required configuration changes by modifying jconfig.h, not by adding -D
  313. switches to the Makefile.  Otherwise you must be sure to provide the same -D
  314. switches when compiling any program that includes the JPEG .h files, to ensure
  315. that the parameter structures are interpreted the same way.  (This is only
  316. critical for the first few symbols mentioned in jconfig.h, down through
  317. NEED_FAR_POINTERS.)
  318.  
  319. Removing code:
  320.  
  321. If you need to make a smaller version of the JPEG software, some optional
  322. functions can be removed at compile time.  See the xxx_SUPPORTED #defines in
  323. jconfig.h.  If at all possible, we recommend that you leave in decoder support
  324. for all valid JPEG files, to ensure that you can read anyone's output.
  325. Restricting your encoder, or removing optional functions like block smoothing,
  326. won't hurt compatibility.  Taking out support for image file formats that you
  327. don't use is the most painless way to make the programs smaller.
  328.  
  329.  
  330. NOTES FOR SPECIFIC SYSTEMS
  331. ==========================
  332.  
  333. We welcome reports on changes needed for systems not mentioned here.
  334. Submit 'em to jpeg-info@uunet.uu.net.  Also, if ckconfig.c is wrong about
  335. how to configure the JPEG software for your system, please let us know.
  336.  
  337.  
  338. Amiga:
  339.  
  340. Makefiles are provided for Manx Aztec C and SAS C.  I have also heard from
  341. people who have compiled with the free DICE compiler, using makefile.ansi as a
  342. starting point (set "CC= dcc" and "CFLAGS= -c -DAMIGA -DTWO_FILE_COMMANDLINE
  343. -DNEED_SIGNAL_CATCHER" in the makefile).  For all compilers, we recommend you
  344. use jmemname.c as the system-dependent memory manager.  Assuming you have
  345. -DAMIGA in the makefile, jmemname.c will put temporary files in JPEGTMP:.
  346. Change jmemname.c if you don't like this.
  347.  
  348.  
  349. Atari:
  350.  
  351. The project files provided should work as-is with Pure C.  For Turbo C, change
  352. library filenames "PC..." to "TC..." in the project files for cjpeg.ttp and
  353. djpeg.ttp.  Don't forget to select a jmemsys.c file, see Step 3 (we recommend
  354. jmemansi.c).  Also adjust the DEFAULT_MAX_MEM setting --- you probably want it
  355. to be a couple hundred K less than your normal free memory.  Note that you
  356. must make jpeg.lib before making cjpeg.ttp or cjpeg.ttp.  You'll have to
  357. perform the self-test (Step 5) by hand.
  358.  
  359. There is a bug in some older versions of the Turbo C library which causes the
  360. space used by temporary files created with "tmpfile()" not to be freed after
  361. an abnormal program exit.  If you check your disk afterwards, you will find
  362. cluster chains that are allocated but not used by a file.  This should not
  363. happen in cjpeg or djpeg, since we enable a signal catcher to explicitly close
  364. temp files before exiting.  But if you use the JPEG library with your own
  365. code, be sure to supply a signal catcher, or else use a different
  366. system-dependent memory manager.
  367.  
  368.  
  369. Cray:
  370.  
  371. Should you be so fortunate as to be running JPEG on a Cray YMP, there is a
  372. compiler bug in Cray's Standard C versions prior to 3.1.  You'll need to
  373. insert a line reading "#pragma novector" just before the loop    
  374.     for (i = 1; i <= (int) htbl->bits[l]; i++)
  375.       huffsize[p++] = (char) l;
  376. in fix_huff_tbl (in V3, line 42 of jchuff.c and line 38 of jdhuff.c).  The
  377. usual symptom of not adding this line is a core-dump.  See Cray's SPR 48222.
  378.  
  379.  
  380. HP/Apollo DOMAIN:
  381.  
  382. With system release 10.4 or later, makefile.ansi should work OK.  If you have
  383. version 10.3.anything, you need to figure out whether you have the ANSI C
  384. compiler (version 6.7 or later) and whether you've installed the ANSI C
  385. include files (if so, the first line of <stdio.h> will mention ANSI C).
  386. If you have the ANSI C compiler but not the ANSI C include files, use
  387. makefile.ansi and add -DNONANSI_INCLUDES to CFLAGS.  If you have both,
  388. then makefile.ansi should work as is.  If neither, use makefile.unix.
  389.  
  390.  
  391. HP-UX:
  392.  
  393. If you have HP-UX 7.05 or later with the "software development" C compiler,
  394. then you can use makefile.ansi.  Add "-Aa" to the CFLAGS line in the makefile
  395. to make the compiler work in ANSI mode.  If you have a pre-7.05 system, or if
  396. you are using the non-ANSI C compiler delivered with a minimum HP-UX 8.0
  397. system, then you must use makefile.unix (and do NOT add -Aa).  Also, adding
  398. "-lmalloc" to LDLIBS is recommended if you have libmalloc.a (it seems not to
  399. be present in minimum 8.0).
  400.  
  401. On HP 9000 series 800 machines, the HP C compiler is buggy in revisions prior
  402. to A.08.07.  If you get complaints about "not a typedef name", you'll have to
  403. convert the code to K&R style (i.e., use makefile.unix).
  404.  
  405.  
  406. Macintosh MPW:
  407.  
  408. We don't directly support MPW in the current release, but Larry Rosenstein
  409. reports that the JPEG code can be ported without very much trouble.  There's
  410. useful notes and conversion scripts in his kit for porting PBMPLUS to MPW.
  411. You can obtain the kit by FTP to ftp.apple.com, file /pub/lsr/pbmplus-port*.
  412.  
  413.  
  414. Macintosh Think C:
  415.  
  416. You'll have to prepare project files for cjpeg and djpeg; we don't include
  417. those in the distribution since they are not text files.  The COBJECTS and
  418. DOBJECTS lists in makefile.unix show which files should be included in each
  419. project.  Also add the ANSI and Unix C libraries in a separate segment.  You
  420. may need to divide the JPEG files into more than one segment; you can do this
  421. pretty much as you please.
  422.  
  423. If you have Think C version 5.0 you need not modify jconfig.h; instead you
  424. should turn on both the ANSI Settings and Language Extensions option buttons
  425. (so that both __STDC__ and THINK_C are predefined).  With version 4.0 you must
  426. edit jconfig.h.  (You can #define HAVE_STDC to do the right thing for all
  427. options except const; you must also #define const.)
  428.  
  429. jcmain and jdmain are set up to provide the usual command-line interface
  430. by means of Think's ccommand() library routine.  A more Mac-like interface
  431. is in the works.
  432.  
  433.  
  434. MS-DOS, generic comments:
  435.  
  436. The JPEG code is designed to be compiled with 80x86 "small" or "medium" memory
  437. models (i.e., data pointers are 16 bits unless explicitly declared "far"; code
  438. pointers can be either size).  You should be able to use small model to
  439. compile cjpeg or djpeg by itself, but you will probably have to go to medium
  440. model if you include the JPEG code in a larger application.  This shouldn't
  441. hurt performance much.  You *will* take a noticeable performance hit if you
  442. compile in a large-data memory model, and you should avoid "huge" model if at
  443. all possible.  Be sure that NEED_FAR_POINTERS is defined by jconfig.h or by
  444. the Makefile if you use a small-data model; be sure it is NOT defined if you
  445. use a large-data memory model.  (As distributed, jconfig.h defines
  446. NEED_FAR_POINTERS if MSDOS is defined.)
  447.  
  448. The DOS-specific memory manager, jmemdos.c, should be used if possible.
  449. (Be sure to install jmemdos.h and jmemdosa.asm along with it.)  If you
  450. can't use jmemdos.c for some reason --- for example, because you don't have
  451. a Microsoft-compatible assembler to assemble jmemdosa.asm --- you'll have
  452. to fall back to jmemansi.c or jmemname.c.  IMPORTANT: if you use either of
  453. the latter two files, you will have to compile in a large-data memory model
  454. in order to get the right stdio library.  Too bad.
  455.  
  456. None of the above advice applies if you are using a 386 flat-memory-space
  457. environment, such as DJGPP or Watcom C.  (And you should use one if you have
  458. it, as performance will be much better than 8086-compatible code!)  For
  459. flat-memory-space compilers, do NOT define NEED_FAR_POINTERS, and do NOT use
  460. jmemdos.c.  Use jmemnobs.c if the environment supplies adequate virtual
  461. memory, otherwise use jmemansi.c or jmemname.c.
  462.  
  463. Most MS-DOS compilers treat stdin/stdout as text files, so you must use
  464. two-file command line style.  But if your compiler has the setmode() library
  465. routine, you can define USE_SETMODE to get one-file style.  (Don't forget to
  466. change the "make test" script in the Makefile if you do so.)
  467.  
  468. If you add more switches to CFLAGS in the DOS-specific makefiles, you are
  469. likely to run up against DOS' 128-byte command line length limit.  In that
  470. case, remove some "-Dsymbol" switches from CFLAGS and instead put
  471. corresponding "#define symbol" lines at the head of jinclude.h.
  472.  
  473.  
  474. MS-DOS, Borland C:
  475.  
  476. Be sure to convert all the source files to DOS text format (CR/LF newlines).
  477. Although Borland C will often work OK with unmodified Unix (LF newlines)
  478. source files, sometimes it will give bogus compile errors.
  479. "Illegal character '#'" is the most common such error.
  480.  
  481. Some versions of Borland's MAKE erroneously display the warning message about
  482. creating jmemsys.c, even after you have done so.  If this happens to you,
  483. delete the four lines beginning with "jmemsys.c:" from the Makefile.
  484.  
  485.  
  486. MS-DOS, DJGPP:
  487.  
  488. Use makefile.ansi and jmemnobs.c, and put "-UMSDOS" in CFLAGS to undo the
  489. compiler's automatic definition of MSDOS.  Also put either "-DUSE_SETMODE" or
  490. "-DTWO_FILE_COMMANDLINE" in CFLAGS, depending on whether you prefer one-file
  491. or two-file command line style.  (If you choose two-file style, change the
  492. "make test" section of the Makefile accordingly.)  You'll also need to put the
  493. object-file lists into response files in order to circumvent DOS's 128-byte
  494. command line length limit at the final linking step.
  495.  
  496.  
  497. MS-DOS, Microsoft C:
  498.  
  499. Old versions of MS C fail with an "out of macro expansion space" error
  500. because they can't cope with the macro TRACEMS8 (defined in jpegdata.h).
  501. If this happens to you, the easiest solution is to change TRACEMS8 to
  502. expand to nothing.  You'll lose the ability to dump out JPEG coefficient
  503. tables with djpeg -debug -debug, but at least you can compile.
  504.  
  505. Original MS C 6.0 is buggy; it compiles incorrect code unless you turn off
  506. optimization (remove -O from CFLAGS).  That problem seems to have been fixed
  507. in 6.00A and later versions.  6.00A still generates a bogus "conditional
  508. expression is constant" warning in jrdppm.c, but the emitted code seems OK.
  509.  
  510.  
  511. SGI:
  512.  
  513. Use makefile.ansi, but set "AR2= ar -ts" rather than "AR2= ranlib".  Also
  514. make any changes recommended by ckconfig.c.
  515.  
  516.  
  517. Sun:
  518.  
  519. Don't forget to add -DBSD to CFLAGS.  If you are using GCC on SunOS 4.0.1 or
  520. earlier, you will need to add -DNONANSI_INCLUDES to CFLAGS (your compiler may
  521. be ANSI, but your system include files aren't).  I've gotten conflicting
  522. reports on whether this is still necessary on SunOS 4.1 or later.
  523.